In computer programming a thread is a placeholder for information associated with a single use of a program that can handle multiple concurrent users. From the program's point-of-view, a thread serves one individual user or a particular service request. If multiple users are using the program or concurrent requests from other programs occur, a thread is created and maintained for each of them. The thread allows a program to know which user is being served as the program alternately gets re-entered on behalf of different users.
Multiple threads can be executed in parallel on many computer systems. This multithreading generally occurs by time slicing (similar to time-division multiplexing), wherein a single processor switches between different threads, in which case the processing is not literally simultaneous, for the single processor is really doing only one thing at a time. This switching can happen so fast as to give the illusion of simultaneity to an end user. For instance, many personal computers today only contain one processor core, but one can run multiple programs at once, such as typing in a document editor while listening to music in an audio playback program; though the user experiences these things as simultaneous, in truth, the processor quickly switches back and forth between these separate processes.
Multithreading is a popular programming and execution model that allows multiple threads to exist within the context of a single process, sharing the process' resources but able to execute independently. The threaded programming model provides developers with a useful abstraction of concurrent execution.
There are scenarios where an application located on an application server may start multiple threads for processing a single client request. For example, a weather application may need to include different meteorological information from different sources as every source is presented by an additional application. One source may provide temperature, another source wind speed, a third source may provide humidity, and so on. In this case, the weather application creates a number of new threads. Each of these threads has to process the initial client request in the corresponding application of the number of applications. In terms of Java 2 Platform, Enterprise Edition (J2EE), this means that the initial client request has to be forwarded to these applications. The new threads share the same client request and client response objects.
The request object has application context and session relative information associated with it, such as context path, servlet path, session information, etc. Each Web application is mapped to its own servlet context. This allows a Web container to route user requests to the appropriate application based on the requested Uniform Resource Identifier (URI). In terms of J2EE, application context and servlet context have same meaning. The servlet context defines a servlet's view of the Web application within which the servlet is running. Using a servlet context object, a servlet can log events, obtain Uniform Resource Locator (URL) references to resources, and set and store attributes that other servlets in the context can access. A session usually corresponds to one user, who may visit a site many times. The server can maintain a session in many ways such as using cookies or rewriting URLs. Common information stored in session variables is name, id, and preferences. The server creates a new session object for each new user, and destroys the session object when the session expires.
There may be a number of problems related to the scenario described above. One problem may be related to the session management mechanism. Each application context is associated with one session domain. To forward the request from one application to another, the application context has to be switched. Switching the application context means switching of the session domain. Each session domain has corresponding session handler and session request objects. In this context, switching the application context means replacing the current session with a new session related to the target application. This new session becomes the active one. When another thread (in parallel) tries to switch to the same context, it may be a problem because this may replace the newly created session with a new one.
Another problem may be with the context related information such as the context path and the servlet path. Context path and servlet path are request path elements. The request path leads to a servlet servicing a request. When two parallel threads are processing the same request in two different application contexts, it is not guaranteed that this information is correct for each of the threads, as each of them can change it according to its own needs. This problem comes from the Java™ Servlet specification. According to the specification (SRV. 8), when the request is forwarded by a request dispatcher to another application, the path element of the request object exposed to the target servlet must reflect the path used to obtain the request dispatcher. In that way the second application will overwrite the path elements set in the request during first forward of the request.
One embodiment of having one and the same request and response objects in all processing threads but with different context and session information is to associate this information with the processing thread's thread context. In addition, the request objects need to be thread safe. In computer programming, thread safety describes a program portion or routine that can be called from multiple programming threads without unwanted interaction between the threads. By using thread safe routines, the risk that one thread will interfere and modify data elements of another thread is eliminated by circumventing potential data race situations with coordinated access to shared data.